Add Show Next/Previous Tab to the Window menu (#418) - #432
Add Show Next/Previous Tab to the Window menu (#418)#432webdevtodayjason wants to merge 1 commit into
Conversation
acfc464 to
7eebf03
Compare
|
Thanks, this now meets the contribution policy. I've cleared the |
|
Refreshed: rebased onto current main (was 115 commits behind) and fixed the CI failure — the June |
Tab switching already worked via Ghostty's next_tab/previous_tab bindings but wasn't exposed as menu items, so it wasn't discoverable and couldn't be rebound from System Settings. Add 'Show Next Tab' / 'Show Previous Tab' to the Window menu, routed through the existing performBindingAction path (next_tab / previous_tab) so custom bindings are honored. Mirrors the splitTerminal wiring: reducer actions + FocusedActions published from WorktreeDetailView, gated on an active worktree. The binding action surfaces as GHOSTTY_ACTION_GOTO_TAB and lands on the same selectTab path the tab bar and Select Tab shortcut use, so it composes with tab hibernation. Classify both actions in AppFeature.Action.affectsWorktreeMenuSnapshot, the post-reduce gate that deliberately has no default arm: neither action writes a snapshot input, so both belong with the other terminal-routing actions. Adds AppFeatureTabNavigationTests covering both directions and the no-selection no-op.
7eebf03 to
3c0471b
Compare
|
I just realized I didn’t explain why I’m withholding the merge. Apologies, I thought I had left a comment. 🙇♂️ |
What
Closes #418. Tab switching already works via Ghostty's
next_tab/previous_tabbindings, but there were no menu items for it — so it wasn't discoverable, and (as the issue notes) you couldn't rebind it from System Settings ▸ Keyboard ▸ Shortcuts, which keys off menu titles.Change
Adds Show Next Tab / Show Previous Tab to the Window menu (the macOS-conventional home for tab navigation).
Both route through the existing
performBindingActionpath with thenext_tab/previous_tabbinding strings — the same path Ghostty keybindings use — so any custom user bindings are honored, and there's no new tab-selection logic (the existinghandleGotoTabRequestdoes the work).Wiring mirrors the existing
splitTerminalaction end-to-end:AppFeatureactions (showNextTab/showPreviousTab)FocusedActions published fromWorktreeDetailView, gated on an active worktreeWindowCommandswith the Ghostty shortcut shownTest
AppFeatureTabNavigationTestscovers both directions forwarding the correct binding and the no-selection no-op.